Collection of Internet

home *** CD-ROM | disk | FTP | other *** search

/ Collection of Internet / Collection of Internet.iso / msdos / wattcp / loadsys.doc < prev next >

Wrap

Text File | 1992-03-05 | 129.3 KB | 2,740 lines

* C:\DOC\LOADSYS.DOC ***** 5 MAR 92 ** 10:32 ******; G W Robinson R A L I B M P C U S E R G U I D E ----------------------------------------- LOADSYS TSR and Device Driver loader/unloader --------------------------------------------- Contents ======== 1. Introduction and Disclaimer 2. Overview 2.1 Interrupts 2.2 Memory Allocation 2.3 TSRs 2.4 Device Drivers 2.5 I/O Port and Memory Modification 2.6 LOADSYS features 2.7 Loading at different positions in memory 2.8 Upper Memory 2.9 Extended Memory 2.10 Expanded Memory 2.11 Expanded Memory Managers 2.12 LOADSYS Support of EMMs 2.13 Moving system code and data 2.14 Summary 3. LOADSYS 3.1 Description 3.2 Notes 4. Usage Guidelines 4.1 BAT files 4.2 Upper Memory 4.3 Control Programs (Windows 3 and DESQview) 4.4 Additional Features 5. Worked Examples 5.1 PRINT 5.2 Communications Cards 5.3 RAINBOW 5.3.1 RAINBOW over BICC 8 bit card MPS v3 5.3.2 RAINBOW over BICC cards using MPS v4 5.3.3 RAINBOW over BICC cards using Packet Driver 5.3.4 RAINBOW over other cards using Packet Driver 5.4 TCP/IP 5.4.1 PC/TCP over BICC cards 5.4.2 PC/TCP over other cards using Packet Driver 5.5 PC-NFS 5.5.1 PC-NFS over Packet Driver 5.5.2 PC-NFS over 3COM cards 5.6 PC3270 5.7 MOS2 5.8 Upper Memory 6. Bugs/Features and Problem Programs 7. Differences in LOADSYS versions 8. Support and Acknowledgements 1. Introduction and Disclaimer ============================== The author and his employers accept no responsibilty for any damage done by this software. It is run strictly at the users risk and all necessary precautions, such as backing up of discs, should be taken before hand. This document descibes LOADSYS which is a program that can load and unload Terminate and Stay Resident programs (TSRs) such as PRINT and also Device Drivers such as ANSI.SYS and VDISK.SYS. For Device Drivers this means that they no longer have to be defined in CONFIG.SYS and loaded when the PC is booted up. They can be loaded when needed by LOADSYS and unloaded when not required thus removing the need to reboot the machine when the memory they occupy is needed by other programs. For TSRs which do not have an unload facility LOADSYS allows them to be removed from memory when they are no longer required. LOADSYS also contains a host of supporting features. These include memory and I/O port reading and resetting and the listing of internal DOS tables. LOADSYS is also able to interface to expanded memory via drivers that support the LIM 3.2 or 4.0 interface. These include systems that map extended to expanded memory such as are found on 386 machines. However as with all good things there are some drawbacks. LOADSYS has only limited facilities to shut down the program it is unloading. Hence you have to use some commonsense before doing an unload. For example unloading PRINT while it is still printing is not a good idea. Similarily unloading a communications TSR whilst it is in use may have undesired effects. A second drawback is that although the unloading process frees the memory used by the Device Driver or TSR this may result in a gap in memory because of other programs that have been loaded after it. LOADSYS is able to move programs down memory to fill such holes but there is no guarantee the program would still work correctly - in fact it is highly likley it would fail hence the facility should be used with care. It is prudent to take account the order of loading programs when several are involved. LOADSYS was developed and tested mainly under DOS 3.3 though it should work on all versions of DOS from 2.0 to 5.0. DOS 5 is rather special in that it introduces its own memory management facilities and LOADSYS is able to interface to these. It has not been tested under OS/2 and is unlikely to work in that environment. A list of problem programs is given near the end of this document. The current version is 1.4b and it contains enhancements to cope with DOS 5 and memory managers. Note that as this needed major recoding there are likely to be problems that have not yet been found. V1.3 will therefore remain available until 1.4 is proven. Changes from previous versions are noted at the end of this file. 2. Overview =========== This section gives an overview of how LOADSYS works. It is essential reading only if you wish to use the expert facilities or to understand a little of whats going on. 2.1 Interrupts -------------- Before describing how LOADSYS works it is necessary to understand a little about some of the features of the PC. The first one to consider is an interrupt and these are generated by two possible means. Hardware interrupts are generated by a hardware event such as pressing a key on the keyboard or the timer tick that occurs 18.6 times per second. Software interrupts are generated by programs using the INT instruction and are used to access the facilities of the BIOS and DOS such as writing to the screen or reading input from the keyboard buffer. There are a maximum of 256 different interrupts and the first 1K bytes of memory on a PC holds the table of four byte Interrupt vectors which are pointers to the code that services each interrupt. 2.2 Memory Allocation --------------------- A second feature is memory allocation. This is managed by DOS and programs and subsystems within DOS can request blocks of a given size. Memory is allocated in multiples of 16 byte units known as paragraphs and all pointers to memory blocks are in terms of paragraphs. This means that the 1Mbyte memory space of a PC can be accessed via 2 byte(16 bit) pointers know as segment or paragraph pointers. Each block is preceded by a one paragraph header which contains details of its owner and how many paragraphs long the block is. 2.3 TSRs -------- A major subsystem in DOS is the program loader (EXEC). This works by asking DOS for a block of memory to hold a copy of the DOS Environment (shown by the DOS SET command) and then for a second block to hold program itself. The program block starts with 256byte (Hex 10 paragraphs) Program Segment Prefix (PSP) which is used by DOS to control the running of the program. A normal program releases all its memory on termination. Those that dont are known as Terminate and Stay Resident (TSR) programs and these exit back to DOS via a special call which leaves them resident in memory. Once a TSR has returned control back to DOS it needs some mechanism to reactive itself. It does this by linking in to an interrupt, such as the timer if it needs regular activation, or the keyboard if just wants to react to certain key presses. It does this by copying the contents of the appropriate Interrupt vector and replacing it by a pointer to an interrupt handler in its own code. Thus when the Interrupt is activated the TSR code is executed and usually this ends by jumping via the original Interrupt vector to the previous interrupt handler. It is therefore quite possible for several TSRs to form a chain of programs that are activated by one interrupt. Thus removing a TSR from the middle of such a chain is rather difficult without the cooperation of the preceding TSR in the chain since there is no way of knowing where the latter has stored the next Interrupt vector in the chain. Before loading any program LOADSYS notes down all the Interrupt vectors. For a TSR it then loads and runs the program. On termination any changes to the Interrupt vectors are stored in small block of memory which will be referred to as the LOADSYS Control Block. This Control Block enables LOADSYS to know which TSRs it has loaded and contains sufficient information to allow them to be unloaded subject to certain conditions. In theory unloading a TSR simply requires the Interrupt vectors to be returned to their original values and the memory occupied by the TSR to be released. However if another TSR has added itself to the Interrupt chain LOADSYS has no means of telling the preceding Interrupt handler the new next member in the chain. If this happens then LOADSYS is unable to unload the TSR. To get round this problem the /r option on LOADSYS redirects the Interrupt vectors used by a program via the Control Block. Thus any further program will record an Interrupt vector that points to the Control block so that by judicious changing of pointers within the Control Block a program can be unloaded leaving the Control Block to take care of its position in the Interrupt vector chain. Only when it is the start of all the Interrupt vector chains is the Control Block removed from them and deleted. Because it may have a life much longer than a TSR the Control Block is kept at the top of the DOS memory - just before 640K on most PCs. TSRs are loaded at the bottom of memory as are normal programs. 2.4 Device Drivers ------------------ Device Drivers are treated in much the same way except that they have to be linked in to a series of lists within DOS. This becomes especially tricky for Block Device Drivers (further details in the DOS Technical Reference). A typical Block Device Driver is the virtual disc driver VDISK.SYS. Because some of the information is held in a table rather than a chain it is very difficult to remove all but the last Block Device Driver so that is all that is allowed. Fortunately most Device Drivers are of the Character type which is much easier to deal with. Because Device Drivers are normally loaded when DOS is booted up they sometimes make assumptions about the state of the machine. VDISK, for example, checks the memory it has been loaded into and, if it finds traces of itself, assumes that a warm start of the machine (Ctrl+Alt+Del) has occurred and that the virtual disc has all its files intact. It can do this because VDISK.SYS is always loaded into the same area of memory at boot up. Unfortunately for LOADSYS this cannot be assumed so the feature is inhibited by clearing the memory before any Device Driver is loaded and also the BIOS flag indicating a warm start is unset. 2.5 I/O Port and Memory Modification ------------------------------------ When a program is unloaded by LOADSYS it may be necessary to close down a communications card or disable an interrupt in order to avoid crashing the machine. The /p option permits this by allowing an I/O Port to have its value reset when a program is unloaded. The entire value or just selected bits may be reset. The /p option also allows I/O Port values to be displayed thus facilitating the setting up of this option. I/O Port usage can be found in the appropriate Technical Reference manuals and great care is needed in setting them. Note also that reading some ports clears the setting and this could adversely affect a program using that port. The /m option provides the same facility for inspecting and changing memory locations. 2.6 LOADSYS features -------------------- Both TSR and Device Drivers loaded with the /r option can be disabled (/d) by removing them from the Interrupt vector chains and the DOS lists. The program is not removed from memory and can be enabled (/e) again. It will preserve its previous state thus VDISK will still contain any files that had been written to it. Whilst the majority of programs will add themselves into the chain of Interrupt vectors at initialisation and thus be noted by LOADSYS there are some exceptions. LOADSYS therefore checks before unloading or disabling a program to see if there are any extra Interrupt vectors pointing into it. If so then the action is refused and an indication given how this limitation can be overcome if the Interrupt is not actually being used by the program. The /i option allows such Interrupts to be specified at load time and thus overcomes the problem. Another variation on Interrupts is when loading a program can change an Interrupt vector yet it does not point into the program. This is referred to as a side effect and is reported by LOADSYS unless the /os option is given. Specifying such Interrupts via the /i option allows them to be reset when the program is unloaded. When several TSRs or Device Drivers are loaded and then some are unloaded it is possible to leave gaps in memory when the unloading is not last in - first out. This should be avoided by loading programs in the right order but should this not be possible then LOADSYS with the squeeze (/q) option can move programs down memory to fill the gaps. This is VERY DANGEROUS since it assumes the programs are relocatable at run time and this is not the case for the majority. ANSI.SYS works but VDISK does not and should a failure occur then the machine will probably crash. A much safer way is to unload and the load the program again though note that this will reinitialise it. Any program that is going to be moved must be loaded with the /f (free) option. 2.7 Loading at different positions in memory -------------------------------------------- Similarily it is possible to load programs into the top of memory by using the /t option. This is not as useful as it might be due to most programs reducing their memory requirements when they become resident and discard their initialisation code. Thus there is likely to be an unusable gap at the top of memory. A second problem is that programs loaded into the bottom of memory are given all the available free memory. When they are loaded at the top of memory this is not practicable so they are loaded in the minimum specified. This is frequently not enough so the /z option can specify the size of memory to be used for loading. Loading the program in low memory with /z and no value will give an indication of its requirements. A subsiduary problem is the location of the programs stack. If this is not explicitly defined in the program then it is initially located at 64K ie the end of the .COM program address space. When a program is loaded at the top of memory this would waste a lot of memory so a 32 byte stack is added onto a programs stated size unless the /z option has been used when the stack is placed at the end of the program address space. Note that even when a program sets up its own stack there must be a valid stack available when the program starts in order to cope with timer interrupts and the like that occur before the program has setup its own stack. It takes 24 bytes to store the state of the machine. Note that when a program is loaded at the top of memory the Control Block is put into the bottom of memory. However if the /oa option is given then the Control Block is put in the same part of memory as the program. Programs may also be loaded at a specified point in memory by using the /w option. This can either be within the DOS 640K space or in any other memory below 1 Mbyte. The latter can be memory held on device cards (ie the monochrome screen on a two screen PC) or any memory space obtained from memory mapping software or hardware - see next section. Care is needed to make sure nothing else uses the memory whilst the program is loaded into it. An alternative way to use memory above 640K is to extend the DOS memory block chain into this region using the /b option and in this case LOADSYS will load programs in this area in preference to normal low memory. Programs can also be loaded at an address greater (/wg) or less than (/wl) that specified. When programs can also be moved to and from the top of memory using the /q option and the /t & /w options determine where it is located. 2.8 Upper Memory ---------------- Having developed a program loader one obvious extension is to load programs in the memory gaps between 640K and 1Mbyte. To do this you need some form of memory mapping which gives the impression that such memory exists. Due to its memory mapping hardware this is possible on 386 PCs and the present implementation is targeted at these. There are several commercial products that do this such as QEMM and 386MAX and under DOS 5 the DOS=UMB command in CONFIG.SYS in conjunction with HIMEM.SYS and EMM386.SYS provides a similar facility. LOADSYS does not seek to copy them since this would need a lot of effort which cannot be justified. Rather it seeks to provide a poor mans halfway house by interfacing to what is already available. These are the LIM v3.2, EMS/LIM v4.0 and XMS v2.0 interfaces. Before explaining what LOADSYS supports it is perhaps useful to explain the different types of memory for those who are unclear in this area. The original PC was based on a 16 bit processor which had an address size of 20 bits and can thus address upto 1Mbyte of memory. When it designed the PC, IBM decided to only use the first 640K of this address space for programs and to reserve the remainder for the system side of the PC. Thus the ROMs that provide the BIOS (Basic Input Output System), BASIC and support for new features such as EGA cards are all situated in the 640K to 1Mbyte gap. The screen buffers are also in this region. The important point is that the whole of this area is not used. There are gaps in the address space that are not occupied and it is the exploitation of this allows the PC to gain extra memory. This area of the address space between 640K and 1Mbyte will be referred to as upper memory - the memory below 640K being referred as lower memory. The crucial thing to note is that most code will execute wherever it is situated in lower or upper memory. Thus if you can somehow install memory in the gaps is this area then it has the potential of being used to run programs. 2.9 Extended Memory ------------------- The original address limitation of 1Mbyte was removed by the arrival of the 286 processor in the PC/AT and its various clones. Whilst it is possible to address up to 16Mbytes with this machine you have to switch it into a different addressing mode and then you cannot run DOS or any of the programs that run under it without major modification. Switching back to the original mode is also a tortuous process which involves rebooting the machine! The memory that is situated above 1Mbyte is referred to as Extended memory because it is an extension of the original 1 Mbyte address space. There is now a standard known as Extended Memory Specification (XMS) v2.0 which defines how a system can manage not only memory above 1 Mbyte but also the upper memory between 640K and 1 Mbyte. 2.10 Expanded Memory -------------------- A second solution, which can also be used on the original 8088 based PC/XT machines, is to add extra memory and provide a special mechinism to access it. This is done by the hardware mapping 16K byte areas (called pages) of this memory onto a suitable gap in the upper memory address space. This window onto the extra memory can be moved around thus giving access to it all but only in 16K pages. The technique is known as bank switching and the memory is referred to as Expanded memory. The standard defining the mapping interface was originally known as LIM and there are two versions, 3.2 which limits you to four adjacent 16K byte pages in a 64K frame, and 4.0 which allows you to use any 16K gap in upper memory as a page. The latest definition is the Expanded Memory Specification (EMS) 4.0. 2.11 Expanded Memory Managers ----------------------------- A final twist to the senario is that the 386 processor has much better memory management and this permits software to be written which makes Extended memory (ie that above 1Mbyte) appear to be Expanded memory. Such Expanded Memory Managers (EMM) can thus be used to fill all the gaps in the upper memory area. Some also implement the XMS interface to upper memory. The technique used requires the machine to be run is a special mode known as Virtual 8086 and this can give interesting problems. Several products for 386 machines provide these features. One of simplest is EMM386.SYS supplied by Microsoft either with DOS 4, or a smaller but inferior version with Windows 3, both of which provide a EMS 4.0 interface to the Extended memory. More sophisticated systems are QEMM and 386MAX which combine a EMS 4.0 interface, XMS and their own memory management which permits programs to be loaded into upper memory and also allows the EMS 4.0 interface to be used. DOS 5 in conjunction with HIMEM.SYS and its version of EMM386.SYS provides similar facilities. Compaq machines have CEMM which is version of the early Microsoft software. Any machine with an Expanded memory board and driver can also be used. Note that PC-DOS 4 does not include EMM386 and only the Windows and DOS 5 versions will run on a PS/2. 2.12 LOADSYS Support of EMMs ---------------------------- LOADSYS therefore provides the ability to interface onto an EMM which conforms to the LIM 3.2 or EMS/LIM 4.0 specification. It can use any of the memory pages up to 1Mbyte via the /xp option which prevents any other programs from using this interface or /xl which allows LIM access as well. LOADSYS can also interface onto an XMS v2.0 interface which provides upper memory via the /xx option. Under DOS 5 where HIMEM.SYS is used with the CONFIG.SYS command DOS=UMB,HIGH the LOADSYS will automatically load programs into upper memory. On a 386 machine with a VGA most EMMs can supply 160K of upper memory. With sophisticated systems such as QEMM this can increase to 192K and if graphics are not required then 240K is possible. The only exception in the PS/2 where the Advanced BIOS reduces all these values by 64K. The total available memory is reduced by the low memory occupancy of the EMM which in the case of QEMM is 2Kbytes and MS-DOS 4 EMM386 is 37Kbytes. The Windows 3 version of EMM386 which must be run alongside HIMEM uses only 10K bytes but note this does not support DMA so BICC 16 bit & MCA drivers wont work under it. This limitation is not shared by the DOS 5 version. When upper memory is available LOADSYS will use it by default. LOADSYS detects the use of Expanded, Extended and HMA memory by a program and release this memory when the program is unloaded. It will also note any extension to the chain of XMS drivers and reset it at unloading provided it is the first in the chain. 2.13 Moving system code and data -------------------------------- Various parts of the DOS system can be moved by LOADSYS and if upper memory is present this will be used. The buffers specified in the CONFIG.SYS line BUFFERS= can be reduced to 1 and additional buffers allocated by LOADSYS. COMMAND.COM, the DOS Environment and the PS/2 Extended BIOS Data Area can also be moved into upper memory as can the buffer used for running a BAT file. The latter avoids memory fragmentation when TSR's and Device Drivers are loaded and unloaded via BAT files. 2.14 Summary ------------ In summary LOADSYS is a set of tools for loading, unloading and positioning programs in memory. It is very much a suck it and see process for the expert facilities since a lot depends on how a system has been programmed. However once a methodology has been proven it should work reliably. 3. LOADSYS =========== 3.1 Description --------------- The format of a call to LOADSYS is: LOADSYS /options filename params which loads device driver or TSR called filename and runs it with parameters params. /options are optional LOADSYS parameters and are described below. They must precede the filename. Filename can be a full pathname or a file in the current directory or a PATH directory. Filename need not have an extension in which case the first file ending in .SYS, .COM or .EXE will be used. (Notes 1,5 & 32). The following options modify the action taken: ? display this help information a give additional information on what is being done (Note 2) h display this help information l list the TSRs/Device Drivers loaded by LOADSYS. (Note 2) n TSRs/Device Drivers must always be referred to by name. (Note 5) r redirect Interrupts to allow disable/enable and guarantee unloading will work. (Notes 3 and 14) s silent flag - no reporting is done except for a warning or major error. The option /ss surpresses warnings. (Note 30) u unload filename or last TSR/Device Driver loaded. /ur unloads all LOADSYS programs or until a named program is found. (Note 4) xh record current directory as the home directory. (Note 29) !xh return to home directory. Examples are: loadsys ansi Load ANSI.SYS if in a directory in the Path loadsys /u ansi Unload ANSI.SYS loadsys /u Unload last TSR or Device Driver to be loaded loadsys /l List TSRs/Device Drivers loaded via LOADSYS loadsys /r ansi Load ANSI.SYS so it can disable/enable and guarantee unloading loadsys /d ansi Disable ANSI.SYS but dont unload it loadsys /e ansi Enable disabled ANSI.SYS loadsys /xh Record current directory as home loadsys /!xh Return to home directory The following options are for expert use only - some may crash the PC. α is a hexadecimal number, δ is a decimal number, ß is a bit value (0,1 or x - x means dont care): * the remaining text on the command is a comment. (Note 35) 1 filename refers to the first program of this name to be loaded and not the last. (Note 5) 2 force second copy of TSR or Driver to be loaded. (Note 12) 3 do INT 3 prior to running program. (Note 16) b reserve the last paragraph of memory for LOADSYS so DOS memory chain can be extended to upper memory. (Note 19) !b reduce DOS memory chain to lower memory. bαααα:αααα add memory at αααα size αααα paragraphs to DOS memory chain. (Note 19) d disable a TSR/Device Driver - must have loaded with /r e enable disabled TSR/Device Driver f load program as free to be moved in memory. (Note 9) iαα record interrupt αα as chained into at a later date or not to be rediredted. (Note 14) lb list memory blocks. (Note 2) ld list memory blocks. (Note 2) lf list DOS file table. (Note 2) lp list program memory blocks. (Note 2) ls list system features. (Note 2) lx list XMS memory chain. (Note ) mαααα:αααα display value of memory byte αααα:αααα mwαααα:αααα display value of memory word αααα:αααα mαααα:αααα=αα reset memory byte αααα:αααα to αα mwαααα:αααα=αααα reset memory word αααα:αααα to αααα mαααα:αααα=10#δδδ reset memory byte αααα:αααα to decimal value δδδ mwαααα:αααα=10#δδδδδ reset memory word αααα:αααα to decimal value δδδδδ mαααα:αααα=2#ßßßßßßßß reset memory byte αααα:αααα to bit values ßßßßßßßß mwαααα:αααα=2#ßßßßßßßßßßßßßßßß reset memory word αααα:αααα to bit values ßßßßßßßßßßßßßßßß (Note 15) oτ override default options where oτ is one of: oa place control block adjacent to program instead of other end of memory. (Note 10) ob dont extend DOS memory chain into /xl, /xp or /xx supplied memory. (Note 23) od force file to be loaded as a Device Driver. (Note 7) oe force Environment copy to be released. (Note 8) of dont Flush Device Driver before unloading. (Note 18) oh load program into HMA if available. (Note 34) oi use DOS internal loader instead of the one in LOADSYS. (Note 13) ok keep LOADSYS where it is, dont move up memory when loading (Note 33) ol force LOADSYS to load in lower memory despite upper memory being present. (Notes 6 and 19) om dont take note of Expanded, Extended and HMA memory used by the program. (Note 32) oo overlay program out if loads another program. (Note 28) oq quit if a warning occurs. (Notes 31 and 6) or dont enable ROM shadowing at unload or disable at loading. (Note 21) os dont report Interrupt changes that dont point to me (Side Effects) (Note 17) ot force file to be loaded as a TSR. (Note 7) ou load only into upper memory (Note 6) ov notify that program may switch to Virtual 8086 mode and switch off ROM shadowing. (Note 21) pαααα, pwαααα, pαααα=αα, pwαααα=αααα, etc display or reset 8 and 16 bit I/O Port αααα in same way as /m (Note 15) q squeeze memory by moving programs loaded with /f option down memory (up if /t) to remove gaps. (Note 9) t load or move to top of memory. (Note 6) uh unload home directory (/xh) record. (Note 29) wαααα Load program at segment αααα in memory. (Note 6) wgαααα Load program at a memory segment greater than or equal to αααα. (Note 6) wlαααα Load program at a memory segment less than αααα. (Note 6) xbδ increase number of DOS file Buffers to δ. (Note 24) !xb decrease DOS file buffers to original CONFIG.SYS value xc move COMMAND.COM. (Note 25) xd allow DOS access to upper memory. (Note 19) !xd reduce DOS access back to lower memory. xe move DOS Environment. (Note 25) xf remove memory fragmentation caused by LOADSYS (Note 20) !xf allow memory fragmentation. (Note 20) xl as xp but allow 4 pages for LIM access. (Note 23) xlδ as xp but allow δ pages for LIM access. !xl release upper memory if not in use. xp use all memory pages upto 1Mbyte being offered by a Memory Manager via the EMS or LIM interface. (Note 23) !xp release upper memory if not in use. xr switch on ROM shadowing. (Note 22) !xr switch off ROM shadowing. xt move PS/2 Extended BIOS data area. (Note 26) xw move DOS working buffer for BAT files. (Note 27) xx use all memory upto 1Mbyte being offered by a Memory Manager via the XMS interface. (Note 23) xxαααα use only αααα paragraphs of upper memory from XMS !xx release XMS upper memory if not in use zαααα Load program in block of memory size αααα (hex) paragraphs. (Note 11) Examples are: loadsys /d ansi Disable ANSI.SYS but dont unload it loadsys /e ansi Enable disabled ANSI.SYS loadsys /f ansi Load ANSI.SYS so it can be moved in memory loadsys /q ansi Move ANSI.SYS down memory filling any gaps loadsys /qt ansi Move ANSI.SYS to top of available memory loadsys /z ansi Load ANSI.SYS to determine minimum load size loadsys /t /z6B ansi Load ANSI.SYS at top of available memory in 6B paragraphs loadsys /z6B /w9000 ansi Load ANSI.SYS at segment 9000 in 6B paragraphs loadsys /z6B /wgC800 ansi Load ANSI.SYS at segment greater than C800 in upper memory loadsys /2 vdisk Load second virtual disk driver loadsys /i15 himem Load HIMEM.SYS and note INT 15 as this is linked into after startup. loadsys /mw40:72=1234 Set memory word 40:72 to 1234 loadsys /p2D4 Display value of I/O port 2D4 loadsys /p2D4=2#1xxxxxx0 pc3270 Load PC3270.COM and reset I/O port 2D4 at unload by setting bit 7 and clear bit 0 loadsys /xp Use all upper memory provided by EMM. loadsys /!xp Release all EMM provided memory loadsys /xl2 Use all available EMM memory leaving 2 pages for LIM access. loadsys /xx Use all available XMS provided upper memory loadsys /xx1000 Use 64K XMS upper memory loadsys /bD000:1000 Add 64k memory block at D000 to DOS memory chain loadsys /xb20 Increase DOS buffers to a total of 20 loadsys /xb20 /wgC800 Increase DOS buffers to a total of 20 using upper memory above C800. loadsys /xcou Move COMMAND.COM but only if upper memory available loadsys /xf Remove memory fragmentation prior to using Windows 3 3.2 Notes --------- 1. LOADSYS acts just like the normal DOS command processor in searching for a command except that it adds the .SYS file extension onto its list of acceptable filenames and ignores .BAT files. Thus it searches the current directory and then each directory defined by the PATH environment varaible. When no extension is given to the filename each directory is searched first for .SYS extension, then a .COM and finally a .EXE. 2. LOADSYS lists the TSRs and Device Drivers in the order that they were loaded. The /a option will give further details. If the /u option is given without a filename then the programs will be unloaded in reverse order starting from the bottom of the list. If the /lb option is given then LOADSYS lists the memory blocks and gives details of their usage. Adding /a shows blocks marked as the end of the DOS chain with <EOC> and summerises free blocks. It also checks for blocks of memory (orphans) that have not been released when their owners terminated and indicates any LOADSYS control blocks that are still in Interrupt chains. The RAL utility PCCONFIG with the /b option will also give additional details of the memory blocks but note that it gives the address of the 16 byte header block which precedes each memory block. This is one less than the address given by LOADSYS which is the data. Note that only PCCONFIG version 2.0 and later can interpret LOADSYS control blocks. If the /ld option is given LOADSYS lists the DOS Device Driver chain and the list of Block Device Drivers that are present - the latter are usually the various disc drives. Adding the /a option in this case gives further details of the Block Device Drivers and is for diagnostic purposes. If the /lf option is given LOADSYS lists the DOS File Table which is the internal table of all the files that are open. If the /lp option is given LOADSYS lists only those memory blocks containing programs. If the /ls option is given LOADSYS lists the various relevant system features including available free memory. 3. LOADSYS normally notes the Interrupt vectors used by a program and repatches back the old values when the program is unloaded. However this is not possible if a further program has patched itself in to one of the interrupts. LOADSYS gets round this by pointing the interrupts used by a program to its Control Block which redirects them to the correct place in the program. When the program is unloaded the addresses in the Control Block are changed back to the orginal Interrupt values so the program can be deleted. The Control Block is only deleted when LOADSYS can make the correct changes to the Interrupt pointers in DOS and this is checked at each invocation. The /lb option gives details of any such blocks. The Control Block is also used when a TSR or Device Driver is Disabled by LOADSYS since this involves removing the program from any Interrupt chains that it may be in. Note that this option will give problems with those programs that use an interrupt vector to see if they, or an auxiliary program, are already loaded. Examples of this are DOS 2.1 PRINT.COM, the RAINBOW Communications software and Packet Driver ethernet drivers. 4. LOADSYS is unable to unload any program whose Interrupt vectors have been repatched unless it was loaded with the /r option. It is also unable to unload any Block Device Driver that is not the last Block Device. LOADSYS will also refuse to unload a program when unrecorded Interrupt vectors in the range 0 - 7f point into it. This could warn that a program has chained into an Interrupt after it was loaded, in which case use /i to specify the interrupt at load time, or that an interrupt has not been reset by a previous program and this program happens to be in the memory pointed to by the Interupt vector. The option /uu will force unloading to continue. If the /ur option is given then all LOADSYS programs are unloaded starting from the last entry and going back up the list stopping only if a program had been loaded with the /n option or an error occurs. If a filename is also given the unloading starts at the last program of that name to be loaded (unless the /1 option is given) and continues back up the list. See also note 5. LOADSYS can also load and unload Expanded Memory Management (EMM) programs such as EMM386 and QEMM. To unload these programs the option /uu must be given since this is quite dangerous and requires a Protection Violation to be generated. This usually causes the EMM to give an error message and invite the user to respond with an indication of what to do next. The usual reply is C to continue which will cause LOADSYS to finish off the unloading of the EMM. This does not work for 386MAX, since this appears to have no aborting facilities. Note that LOADSYS will refuse to unload an EMM if the memory is still in use and the /!xp or /!xl option has usually to be given on a previous call to LOADSYS. 5. If no name is given LOADSYS will assume the last TSR or Device Driver it loaded is to be acted upon by the unload, squeeze or disable/enable options. If however it was loaded with the /n option then this requires the program to be named before any action is taken. Note that this provides a blocking mechanism for the /ur option (unload repeat). If a program has been loaded more than once then the last one loaded will be the one acted upon. This can be overridden by the /1 option which causes the first one loaded to be acted on. If the name ends in * then this acts as a wildcard and a match is done on any preceding characters. Again it is the last matching entry in loading order that is acted upon unless the /1 option is given. Note that a name of just * will select the last program to be loaded. The /n option may be given on its its own and this forces the last program loaded by LOADSYS to be marked as requiring it to be named. Thus a BAT file which can optionally use TSRs or Device Drivers can ensure that a LOADSYS /ur will remove them all if it first issues a LOADSYS /n to protect any other programs LOADSYS has loaded. 6. LOADSYS will load the TSR or Device Driver by default in low memory (as per a normal program) and put the Control Block at the top of DOS memory. The /t option reverses this but will leave significant gaps at the end of memory. In this case the /z option will probably be required to specify the memory needed by the program. Warning messages are given when LOADSYS makes assumptions regarding the positioning of the programs stack. If however upper memory has been made available via the /b /xp or /xl options or under DOS 5 via the DOS=UMB command in CONFIG.SYS then this will be used in preference to lower memory. This can be overridden by giving the /ol option. The /ou option forces loading in upper memory causing a failure if it is not present. The /oa option causes the Control Block to be loaded in the same area of memory as the program. If the /wg or /wl options are given the program and its Control Block are loaded within the address range specified. Note that the default settings are: /wg0000 /wlA000 ; range 0 to 640K unless upper memory is present when in the absence of the /ol option they are reset to: /wgA000 /wlFFFF ; range 640K - 1M Note that /wg and /wl addresses are compared with the starting paragraph of a suitable free block so that any block spanning the address will be rejected for /wg and accepted for /wl. Thus they are only useful where there is more than one free block available and the /w option should be used for more precise location. The /t and /oa options operate as before. If it is not possible to obtain sufficient memory in the area specified the limits are relaxed first, if it is available, to the whole of upper memory and then to the whole of lower memory. The aim is to load the program if at all possible but this can be overriden by the /oq option which will quit the loading if it is not possible in the area specified. Finally if the /w option is given (without the g or l qualifier) then the program is loaded at that paragraph if free memory exists. This can be anywhere upto 1 Mbyte and could for example be an unused area of memory on a video card. The Control Block and any Environment copy are located in their normal places according to any other relevent options such as /t /wl /wt or /ol. The /oa option causes the Control Block to be placed in the same part of memory as the Environment. Failure to obtain the memory causes the load to abort. Giving the /a option will give further details including where things are loaded. See also note 33. 7. LOADSYS assumes a TSR program ends in .COM or .EXE and a Device Driver ends in .SYS. Where this is not the case then the /od or /ot options may be used to override this feature. Be warned that if you get it wrong then DOS will probably crash. Some TSRs also terminate as if they were normal programs (ie dont execute the DOS Terminate and Stay Resident exit) and leave their resident part in another block of memory. The usual reason is when they want to leave their code at the top of memory. LOADSYS can cope with this case provided the changed Interrupts point to the new program location. If this is not the case LOADSYS will report that the program is not a TSR and it will reset any interrupts that have been changed and thus leave the TSR disabled. If the program actually was a TSR (and not a program infected by a virus) the solution is to give the /ot option but be warned this can give problems as LOADSYS may be unable to locate the programs memory block. 8. Some TSRs dont release their copy of the DOS Environment when they become memory resident - LOADSYS gives a warning when this is the case. Where memory usage is critical LOADSYS can force the Environment to be released and it patches the program into the orginal copy. Should the TSR subsequently access the Environment then it will work provided access is via the pointer in the programs PSP. If however the program took a copy of the Environment pointer then it may fail as this will now point to an undefined area of memory. Note that the Environment copy is often held in the same block for each program invocation so you could well get away with it. Therefore use with care and be prepared for disaster - it usually only saves about 100+ bytes so is maybe not worth the risk. The normal place for loading the DOS Environment copy is below the program itself. Thus if a program frees its Environment copy this could leave a small gap. Whilst this will probably be reused by the next programs Environment copy this can be avoided by using the /oe option which will cause the Environment copy to be loaded at the other end of memory from the program. 9. The /q option squeezes memory by moving the TSRs or Device Drivers loaded with the /f option. This implies the /r option so can only be used on programs which allow interrupts to be redirected or those that cannot are specified by /i. Where the programs are moved to follows the same rules as program loading defined in Note 6. Thus if only low memory is in use then a program at the bottom of memory is moved down filling any gaps. If the /t option is given then the program is moved up to the top of memory. Conversely if the program was at the top of memory then the absense of the /t option would cause it to be moved to the bottom memory. Finally for a program at the top of memory the /t option would move it higher up if possible. If upper memory was available then the program would be moved into that in accordance with same rules unless the /ol option was given. The /r option can also be given to repeat the operation in a similar manner to /ur for unloading programs. This option is VERY DANGEROUS and only works on a few programs such as ANSI.SYS and KEYB.COM. It does not work on PRINT.COM, VDISK.SYS, CED.COM to name just a few. It would be very dangerous to try this feature on a disc caching program! Note that some EXE programs have relocation tables which are implemented on loading. Since these are not recorded then moving such programs is not possible therefore the /f option is ignored and an error message given. 10. LOADSYS Control Blocks are usually located at the opposite end of memory to the program. Thus for normal loading where the program at the bottom of memory the Control Block is at the top of memory (usually just below 640k) . The /oa option forces the Control Block to be located at the same end of memory as the program ie adjacent to it. This option is forced when loading programs in low memory under 4DOS or when fragmentation (option /xf) is not allowed. See also Note 6. Control Blocks are allocated in paragraphs (16 bytes) and the minimum size is 28 bytes for a Device Driver using no interrupts. Recording an Interrupt takes 10 bytes, setting an I/O Port takes 4 bytes and setting memory 6 bytes. Thus a TSR with upto 2 interrupts takes 48 bytes (3 paragraphs) and PRINT.COM with 9 interrupts takes 8 paragraphs. 11. When a program is loaded in low memory it is initially given all the available free memory. On termination when it becomes memory resident it releases what it does not need. When loading a program at the top of memory (/t) or at a specified point (/w) the minimum memory specified in the program header is used. This is frequently too small so /z can be used to give the correct value. Note the units are hex paragraphs. If /z is given without a value, ie followed by a space, LOADSYS will load the program as normal and then give an estimate of the minimum memory required to load it. This is calculated by filling the memory with zeroes and then searching from the end looking for the first bytes that have been changed. If this coincides with where the stack is located then this is passed over and further searching is done. The value finally suggested includes an allowance for the stack. There is no guarantee that this value is correct but it gives a starting value for tests. Note that the loaded size shown on termination is the final memory requirement of the program and is usually smaller that the load size due to the initialisation code having been discarded. Thus the recommended procedure is to load the program with the /z option and no value in low memory which will give the estimated value for /z which can then be used for loading elsewhere in memory. Note that if a program is run with too small a /z value then the program will overwrite the DOS memory block control header and crash the system with the message: Memory Allocation Error. 12. LOADSYS will normally refuse to let you load a second copy of a TSR or Device Driver. However for cases where this is valid such as a second Virtual Disc the /2 option overrides this restriction. 13. LOADSYS has its own internal loader which it uses instead of the one available via DOS. The latter one may be accessed by using the /oi option and is provided just in case a bug in the LOADSYS loader prevents a program from loading or running. It is not recommended that this option is used for loading programs at the top of memory (/t) as it needs a minumum of 64k bytes thus leaving a large gap. It is also not able to load TSRs at a given point or with a given size and any failure is likely to crash the machine. 14. LOADSYS only records those interrupts that are changed when a program is first loaded. However some programs such as HIMEM.SYS chain into Interrupt vectors after they have been loaded. The /i option tells LOADSYS to also record these interrupts. In order to check for such cases LOADSYS checks when a program is unloaded to see if any unrecorded Interrupt vectors point to it. The check is made for 0 to 7F which is the normal range used. If option /i is given without a value, ie followed by a space, then the range is increased to the maximum of FF which is 255 decimal. This will include Interrupt vectors which are used as data areas so can give spurious warnings. This /i option is also used to inform LOADSYS that the specified interrupt should be not be redirected when option /r is in force. This allows a mixture of redirected and direct interrupts. 15. When a program is unloaded by LOADSYS it may be necessary to close down a communications card or disable an interrupt in order to avoid crashing the machine. The /p option allows this by specifying an I/O port and a byte value to be written (using OUT) to the port. For a word port /pw is used. The /m option does a similar job for memory where the αααα:αααα specifies the segment and offset of a byte. To change a word /mw is used. The value may either be a hex or decimal (prefix 10#) number in which case the byte or word is completely changed or a binary pattern (prefix 2#) which allows selected bits to be changed. In this instance values for ß are 0 to clear the bit, 1 to set the bit and x for dont change. If less than the total number of bits are specified then the least significant ones are assumed and the higher bits are left unchanged. An example of selected bit changes is to shut down an interrupt by resetting the interrupt mask on I/O port 21. Thus for IRQ4 this would be /p21=2#1xxxx. The /m or /p option is normally supplied when a program is loaded and is implemented when the program is unloaded. However they can be given on any other call to LOADSYS when they will be implemented immediately. If no value is supplied for the /m or /p option then the memory or I/O port is read and displayed. This can be useful in ascertaining the current value. For the loading and unloading cases the value is displayed before and after the action so any change can be noted. Thus either of the following will cause the value of the port 2F9 to be printed: /p2f9 /p2f9= Note also that reading some ports clears the setting and this could adversely affect a program using that port. On AT and XT type machines the maximum port value is 3ff (hex), on PS/2s this is increased to ffff though there are a lot of instances where the first digit is ignored. Thus in the case of the BICC board where the I/O port is 28c for the 16 bit varient and 828c for the PS/2 MCA version the /p828c would work in on both machines. Further details are given in the section of Worked Examples. 16. The /3 option causes LOADSYS to obey an INT 3 instruction prior to running a program. Normally this will have no effect but when LOADSYS is being run under DEBUG or CODEVIEW this will cause an entry into the debugger. Note that under DEBUG the IP register has to be reset to the next instruction before execution can continue. The facility is mainly for the debugging of Device Drivers. For a Device Driver the INT 3 is obeyed just before the Strategy routine is executed. When this is complete the Interrupt routine is called. For a TSR the next instruction is the jump into the program and the main use in this case is to debug LOADSYS by seeing if registers etc are correctly initialised. 17. If loading a program causes Interrupt vectors to be changed but the new value does not point to the program then this is termed a Side Effect. An example is the loading of SMARTDRV.SYS which causes HIMEM.SYS to link into Interrupt 15. The option /os stops LOADSYS from giving a warning message. The /i option can be used to record the Interrupt so it is reinstated when the program is unloaded. See also note 32. 18. When unloading or disabling a Device Driver, LOADSYS implements a Flush to clear out any buffers. This can be inhibited by the option /of. 19. If memory is available above 640K an alternative to using /w to load programs into it is to include it in the DOS memory block chain. On all systems upto DOS 5 this is by the /b option which causes LOADSYS to extend the chain to 1Mbyte if it has not been done already and to include the specified block. Since the chain must be contiguous the ROM and screen buffers must also be included and these are marked as being owned by the BIOS. The option /lb will list the new situation. Note that the calls that obtain upper memory (/xx, xp and /xl) normally invoke /b so it is only required to be used directly in special cases. In order to extend the DOS memory block chain above 640K LOADSYS needs to be able to use the last paragraph in memory. This is usually available but should it need to be reserved then the call: loadsys /b will keep it for later use by LOADSYS. Once upper memory has been defined via the /b option subsequent loading of programs will use this memory in preference to low memory unless the /ol option is given. Upper memory can be released once it is no longer occupied by the call: loadsys /!b The above should not be used under DOS 5 and later systems where the DOS=UMB command should be used in CONFIG.SYS to achieve the same effect. By default DOS knows nothing about this extra memory even though it has been added to the DOS memory chain. However it can be told about it by the option /xd and this allows programs which ask DOS for further memory to access the upper memory. The /!xd option switches this feature off. See also the /xx /xp and /xl options and Notes 20 and 23. 20. The /xf option attempts to remove the memory fragmentation that control programs such as Windows 3 object to. All LOADSYS control blocks that are located at the top of low memory are moved down the memory. All subsequent program loads in low memory force the /oa option and ignore the /t option to prevent further blocks being located in this area. Fragmentation is automatically allowed again once the control program has been loaded. The option /!xf also allows memory fragmentation to occur. The /xf option also works with DOS 5 when the DOS=UMB command is present in CONFIG.SYS and retrieves the 4K bytes of memory that is normally lost when Windows 3 is loaded. In this case it must be given just before WIndows 3 is loaded since it removes access to upper memory from the LOADHIGH command. The reason for /xf is twofold. Firstly if lower memory is not exactly a multiple of 4K (eg. exactly 640K) then Windows will reduce the lower memory to a value that is (eg 636K). This can occur when the last paragraph is used to extend the memory chaining into upper memory by either LOADSYS or DOS5. Secondly the last block of memory must be the main free block and hence there must be no small blocks at the end of low memory. If there are then Windows 3 will refuse to load complaining of memory fragmentation and DESQview will not show any upper memory that is in use. Thus any such blocks created by LOADSYS must be moved either down low memory or into upper memory if it is available and this one of /xf actions. See the Usage Guidelines Section for further details. 21. LOADSYS has to take special action in order to unload an Expanded Memory Manager (EMM) so such programs have to be noted. This is usually done by checking whether the program has switched the PC into Virtual 8086 mode. However some managers do not switch immediately and the /ov option is provided as an alternate way of notifying LOADSYS. The /ov option is assumed by default for any device driver with a name of the form EMM or ?EMM. On Compaq 386 machines most EMMs also switch off ROM shadowing thus increasing the available number of pages. By default the ROM shadowing is switched back on when any program noted as being an EMM is unloaded by LOADSYS. The /ov option also causes LOADSYS to switch off ROM shadowing when the program is loaded. Giving the /or option overrides both these features. See also note 22 22. On Compaq 386 machines the /xr option will switch on the ROM shadowing and /!xr will switch it off. Note that when ROM shadowing is off then screen updating will be slower. 23. LOADSYS provides the ability to interface onto memory managers supporting the EMS/LIM or XMS interfaces and uses them to provide upper memory. These are not required under DOS 5 where the CONFIG.SYS command DOS=UMB,HIGH should be used. Where the EMS/LIM v4.0 or LIM 3.2 interface is available the option /xp takes all the pages and disables the LIM interface thus making the maximum amount of memory available. Unless the /ob option is given it then does an internal call of the /b option to add this memory to the DOS memory chain. Subsequent calls to LOADSYS will attempt to load programs in the memory unless the /ol (override lower) option is given when low memory is used. For all but LIM 3.2 managers if it is required to run programs which use the EMS/LIM interface then the /xl option should be used instead of /xp. This by default gives four pages (64K) for LIM usage and uses the rest for program loading. /xl can be optionally followed by a number indicating how many LIM pages to use. Note that LOADSYS has to put its own small driver in front of the EMS manager in order to hide the extra pages that it has taken. Sophisticated users of LIM may thus get confused. Once programs have been unloaded by LOADSYS the upper memory can be released by the /!xp or /!xl options. These will abort if the memory is still in use. /!xp or /!xl must also be given before an Extended Memory Manager is unloaded. Alternatively if an XMS v2.0 interface manager is available which provides access to upper memory then this can be utilised via the /xx option. This can optionally be followed by the the number of paragraphs to allocate otherwise all the available upper memory is obtained. Again /!xx releases the memory. If it is required to obtain the available XMS from memory from a given area then use of the /a /xx options without any parameter will show the amount of memory that the XMS provides. Then release the XMS memory (/!xx) and use this value as the parameter. Note the value will be slightly less than expected since the XMS manager uses some paragraphs for its own memory management. /xxαααα can only be used once (unless /!xx is used) except when a control program is present when it can be used from each DOS session subject to their being sufficient available memory. Note that the XMS management of upper memory is done by maintaining a chain of blocks in a similar way the DOS memory management. This has no impact on the use of upper memory unless it is accessed vi aboth the /xx and /xp or /xl options. In this case the EMS/LIM memory would normally have a one paragraph block on either side which was part of the XMS memory management. This would prevent the EMS/LIM free memory from being merged with any adjacent XMS provided free memory. LOADSYS gets round this by removing the EMS/LIM memory from the XMS memory chain and reinstating it when the memory if freed. The XMS memory chain can be listed by the /lx option. 24. DOS 3.x systems use 528 bytes of memory per buffer to impliment the BUFFERS parameter in CONFIG.SYS which occupies lower memory. By giving a small BUFFERS value in CONFIG.SYS (eg BUFFERS=1) and using the LOADSYS option /xb followed by a decimal number then the additional buffers can be allocated from memory in accordance with same rules as for loading programs (Note 6). No value or 0 gives the current buffer count. Thus if upper memory is available via an EMM which has been loaded via CONFIG.SYS then buffers can be allocated from it by the AUTOEXEC.BAT having something something similar to: loadsys /xp ; Use all memory pages above 640K loadsys /xb20 ; Increase DOS buffers to 20 The number can be increased by giving a larger number and also can be reduced back to original CONFIG.SYS value by giving the /!xb option. The latter is actually very dangerous but appears to work - it should only be used for testing purposes. /!xb does not work when the buffers are not held on a DOS buffer chain. This option can also be used under DOS 5 but it is more efficient to use the facilities of DOS 5 to achieve the same effect. In DOS 3.x and DOS 5 systems the buffers are all held in one chain. DOS 4.x systems are different in that the buffers can be held in one or more chains and each chain is held within a 64K segment of memory. DOS uses 532 bytes per buffer and tests suggests that it increases the number of chains when the minimum possible chain size is 15. Thus at BUFFERS=30 it uses two chains and at 45 uses 3. The algorithm implemented by LOADSYS under DOS 4 is as follows and will only operate where DOS is not using EMS to hold its buffers. If the initial BUFFERS value is 1 then the first call of LOADSYS /xb creates a single chain of buffers containing the number specified. Some of the 532 bytes of the original buffer is used for a control block but the bulk is unused. Subsequent calls create additional chains of the same size as the first until the total buffer request is reached. If the request is not modulo the chain size then the excess is ignored. If the initial BUFFERS value is greater than 1 then additional chains of the same size as the first are created. In this case the control block is appended to the front of the first buffer chain added by LOADSYS and contains enough space to add 31 chains. Thus differing combinations of chain size and number can be experimented with to achieve optimal performance. 25. The /xc and /xe options allow the current COMMAND.COM and the DOS Environment to be moved. If a second COMMAND.COM is in use then this is acted upon rather than the primary copy. Under DOS 5 it is only possible to move the secondary copy. Where they move to conforms to the same rules as loading a program (Note 6). Thus if upper memory is available via an EMM driver then both items can be moved to upper memory by the commands: loadsys /xc loadsys /xe Adding the option /a gives further details and /ou aborts the move if upper memory is not available. The /xe option also deletes the superfluous copy of the environment when a second COMMAND.COM is in use if the option /oe is given. Giving the /z option with a size in hex paragraphs allows the Environment size to be increased. Thus when running a second COMMAND.COM (eg under Windows 3) the following will increase the size of the environment to 256 bytes (Hex 10 paragraphs). loadsys /xet /z10 loadsys /xe This works by moving the environment up memory and increasing its size. The second call moves it back down memory and is optional. 26. On the PS/2 IBM introduced the Extended BIOS Data Area (XBDA) which is a 1Kbyte block at the end of normal memory which is outside the normal DOS memory management. This can give problems for programs which convert the video ram into accessible memory. The /xt option allows it to be moved according to the same rules as for program loading defined in Note 6. Thus a call of: loadsys /xt would move the XBDA into low memory and free up the last 1Kbytes. A more useful sequence would be where an EMM driver has been loaded via CONFIG.SYS: loadsys /xt ; move XBDA into bottom of low memory loadsys /xp ; expand memory blocks to upper memory ; alternatively /xx or /xl could be used. loadsys /xt ; move XBDA again - by default it now goes ; to upper memory. Frees 1K of low memory. It has been noted that some systems such as Windows 3 do not work if the XBDA is in upper memory. 27. When DOS executes a BAT file it uses a 64byte buffer as a work buffer and if a TSR is being loaded then this memory leave a hole. Using the /xw option along with /t moves the buffer to the top of memory thus allowing the TSR to be loaded at the lowest possible point. If several BAT files have been CALLed then all working buffers are moved. 28. /oo is an experimental option which allows LOADSYS to run a normal program and monitor if it loads a subsequent program. When this occurs the original program is swopped out of memory thus increasing the available memory. The most usual use is when a program has the facility to execute DOS commands. In order to keep the monitor that LOADSYS leaves in memory to a minimum size (currently 7K) several restrictions and limitations are imposed. The program is always loaded in low memory using the DOS internal loader and it must not be a TSR. No checks on changes to interrupts are done so no checks for a virus are made. It is assumed that a subsequently loaded program makes no use of its parent. If the /oo option is used in any other circumstances then the machine will probably crash. LOADSYS implements /oo by monitoring the use of INT 21 function 4B (EXEC). It only reacts to calls from the program it loaded. It writes the program out to a file @loadsys.@@a in the current root directory (usually C:\) unless this file already exists when the last letter (a) is incremented until a unique name is found. Thus several copies of LOADSYS using this feature can be run. The file is deleted on termination but will be left if the system crashes. 29. The /xh option records the current directory as the home directory and the /!xh option resets the current directory to the home directory. Multiple calls of LOADSYS with the /xh option will stack the various home settings and /!xh will remove the last entry. The option /!xhr will repeatedly implement the /xh settings until no more are present. The /uh option removes the last /xh record with implementing it and and /uhr option removes all such. 30. The /s option stops LOADSYS from giving out anything other than warning or major error messages. /ss surpresses the warnings as well. When the option /s is given then the name LOADSYS is placed in front of most warning and error messages in order to identify their source and the LOADSYS command that generated the error is displayed. 31. The /oq option is designed to allow a LOADSYS command to only be executed if conditions are right. If a warning message is given about the options specified then the command is aborted. Thus the general default that LOADSYS ignores option errors that are not fatal is overridden. See note 6 for its effect on the /w option. 32. LOADSYS detects the use of Expanded, Extended and the HMA memory by a program when it is loaded and releases such memory when the program is unloaded. It will also detect when a program chains into the XMS driver and will correct this at unloading. The option /om overrides these features. Option /a gives details of the use of such memory at loading, unloading and listing via the /l option. Note that LOADSYS is unable to detect if the memory is being used by the program being run or some other system that has been activated as a result. When this side effect occurs then the /om option must be given otherwise when the program is unloaded the memory belonging to the other system will be released and this will probably crash the PC. 33. LOADSYS relocates itself in memory in order to facilitate the loading of programs. Thus it moves itself to near the top of DOS memory when loading a program and the bottom of low memory. If the /t option has been given then it stays put. When loading in upper memory it also moves to the top of DOS memory just in case there is insufficient space in upper memory and the program is forced into lower memory. However there are some cases, such as TSRs which relocate themselves to the top of low memory, where LOADSYS gets in the way and this results a large block of free memory at the top of memory. To overcome this the /ok option tells LOADSYS to keep where it is, that is at the base of low memory. Note if this option is given with a normal TSR or Device Driver then a large block of free memory at the bottom of memory will result. The LOADSYS option /lb will display the memory usage. 34. The option /oh asks LOADSYS to attempt to load a program into the High Memory Area and is of limited use. It is for experts only and may probably crash the PC. It will only work with .COM programs that do not change their segment register when accessing their data. Thus .EXE programs and Device Drivers are excluded. There must also be an XMS manager operating in order to control usage of the HMA (eg. HIMEM.SYS) and the program must not chain into INT 21. Note that only one program at a time may use the HMA. If the HMA is not in use LOADSYS claims it and loads the program starting at address FFFF0. Since this includes the last 16 bytes of the BIOS ROM area the first 16 bytes of the programs PSP will not be correct. Hence the program cannot terminate in the normal manner and so LOADSYS has to catch its exit by monitoring INT 21. Program loading can be done at addresses lower than this via the /w option but note that further parts of the PSP will be incorrect and bizzarre effects may occur. Most notable may be the loss of of all output from the porgram since the I/O handles are held in the second 16 bytes of the PSP. 35. The option /* indicates that the remainder of the command is a comment. It cannot be used when loading programs as it would be included as a parameter to the program. It is useful in BAT files to add comments to LOADSYS commands to remind you what they do and also if the /s option is given the comment is displayed as well as the LOADSYS command should an error occur. 4. Usage Guidelines =================== The following give some general guidelines on usage. See also the Worked Examples Section. 4.1 BAT files ------------- The recommended method of using LOADSYS is via BAT files. Thus the mechanism can be tested out and user finger trouble is avoided. The later section of worked examples illustrates most of the techniques described below. For programs that normally require a Device Driver in CONFIG.SYS a BAT file should be written which uses LOADSYS to load the Device Driver(s) before invoking the main program and then unloads them again afterwards. Similarily programs such as PRINT can be loaded via a BAT file which uses LOADSYS to run PRINT.COM. To retrieve the memory used after printing has finished LOADSYS /U PRINT should do the trick. For systems which may load a variety of programs depending on options selected the following technique is available to simplify the unloading process. The BAT file should have the line loadsys /sn before any programs are loaded which will set the /n option on last program loaded by LOADSYS (if any). The /s avoids worrying the user with an error message if there is no previous LOADSYS loaded program. The unloading can then be achieved by the line: loadsys /ur which will terminate unloading at the named entry. Whilst this technique is suitable for a system where all the LOADSYS calls are within one BAT file it is not satisfactory where say one BAT file loads a system and a second unloads it because the /ur takes no account of any more programs subsequently loaded via LOADSYS. Examples are communications drivers where the kernel is a TSR and various utilities provide the communications applications. The solution is to name of the last program loaded in the unload call for example: loadsys /ur tsr_name where tsr_name is the last program in the group that is to be loaded and thus the first to be unloaded. LOADSYS sets the BAT file ERRORLEVEL at 0 if it is successful and 1 if not. No indication of ignored options is shown unless the option /oq is given when they cause LOADSYS to abort with an ERRORLEVEL of 1. 4.2 Upper Memory ---------------- Where upper memory is going to be used there is a choice of methodologies. EMMs such as QEMM and 386MAX have their own programs to allow loading in upper memory. However they lack the unloading facility so using LOADSYS can be advantageous. It is probably unwise to mix the two though tests with the LOADHIGH of DOS 5 and LOADSYS show they can both be used. Where there is the choice, such as with QEMM, accessing upper memory via the XMS interface (/xx) is better since this allocates in 4K byte units rather than the 16K byte pages used by EMS (/xp and /xl). It is thus usually able to obtain more upper memory. The option /ou is useful for moving items to upper memory since it can be used to abort the action if it does not exist. For example loadsys /xcou will move COMMAND.COM to upper memory but only if it exists. Similarily the /oq option can be used to be more selective in placing a program. Thus the command loadsys /wgE000 /oq program will fail to load if it cannot optain memory above E000 thus allowing a second choice of where to load it. If the /oq had not been given then an attempt would have been made to load the program first in the whole of upper memory and then in lower memory. Note that a BAT file could test the ERRORLEVEL reply to see if it had been successful - for example loadsys /sswgE000 /oq program IF ERRORLEVEL 0 GOTO OK loadsys /sswgD000 /oq program IF ERRORLEVEL 0 GOTO OK loadsys /sswgC000 /oq program IF ERRORLEVEL 0 GOTO OK loadsys /ss program :OK The IF ERRORLEVEL could actually be left out since LOADSYS will refuse to load the program a second time and would thus plough on. The /ss is included so as not to alarm the user. 4.3 Control Programs (Windows 3 and DESQview) --------------------------------------------- LOADSYS is cogniscent of two control programs - Windows 3 and DESQview. These provide a special challange in that on a 386 machine they can provide several DOS sessions. This gives problems with memory management since some memory is shared (eg that below the control program) and some is unique (usually from the end of the control program to 640k). Where upper memory is used then this compounds the problems. Before running a control program all programs loaded via LOADSYS should have the /oa option and the command: loadsys /xf must be given. It is best given just before the control program is loaded but can be given earlier and subsequent program loadings or memory block relocations should conform. It can also be given to DOS 5 when the DOS=UMB command is present in CONFIG.SYS and will retrieve 4K bytes of lower memory that would normally be lost. If it is not given then upper memory will also not be visible since the chaining has been broken. After a control program has been loaded then LOADSYS can be used as before and fragmentation is allowed again. The first use of LOADSYS will remove the fragmentation and reinstate the memory chain to its correct setting. It is therefore recommended that every use of the DOS box commences with the command: loadsys /!xf The /lb option will show the shared and unique areas of memory and program loading/unloading and memory block relocation will be confined to the latter area. If the /xl, /xp or /xx option is used to obtain upper memory then any shared upper memory will cease to be displayed and only that unique to the DOS session will be shown. The only exception is under Windows 3 when /xp or /xl has been used to obtain upper memory before Windows 3 is loaded. Because a unique copy of this area is supplied the upper memory cannot be displayed by /lb. Further upper memory can still be obtained via /xp or /xl. It is strongly recommended the /xx is used to obtain upper memory before loading Windows 3 as /xp or /xl supplied memory can cause it not to load. It has been noted that moving the Extended Bios Data Area (XBDA) on a PS/2 to upper memory causes Windows 3 to fail. 4.4 Additional Features ----------------------- LOADSYS can also be used to run normal programs. It will complain that they are not a TSR but it will also note and correct any changes made to the Interrupts on the system. It is thus useful for testing out any program that may change the Interrupts (such as one that may contain a virus). The /i option is recommended so that all interrupts are checked but be warned that some of the higher interrupts are used as data areas so can confuse the issue. LOADSYS can be used to record the current directory when running a system requires a switch to another directory. Thus a BAT file to run such a system could be of the form: loadsys /xh . . commands to run system . loadsys /!xh LOADSYS can also be used to examine the value of I/O ports or memory locations and also to reset them if required. Thus to examine the value of I/O port 28c you type: loadsys /p28c which will display the value, loadsys /p28c=04 will reset the value to hex 04 and loadsys /p28c=2#xxxxx1xx will set bit 2. Be warned that reading an I/O port can reset its value in some cases - see the appropriate technical documentation. The features in LOADSYS to display various aspects of DOS can be quite useful. For example the /lb option which displays memory blocks gives an insight into what DOS (and also LOADSYS) does with memory. Option /lf shows which files are open and to what programs. Adding /a gives the whole table including all files opened and closed. The /xb option to increase the DOS file buffers can be useful for optimisation of how many DOS buffers are really needed by an application. The number of buffers allocated can be increased between timing an application without having to reboot the machine. If the DOS Environment is too small then introducing new parameters via the SET command can fail with a message to that effect. This can occur when either the Environment is too small or when a secondary Command processor is in use (eg when DOS is invoked from within a program) and the Environment is not expandable. Moving the Environment using the /xe option along with the /z option to define a new size will increase the size of the Environment. For example to increase the size to 512 bytes use: loadsys /xe /z20 As this will leave a gap at the bottom of memory where the old Environment was it is best to move it to the top of memory and then back down again. If this was being done in a BAT file then the recommended sequence is: loadsys /xw /t /* move DOS working buffer for BAT file up loadsys /xe /t /* DOS Environment up memory loadsys /xe /z20 /* DOS Environment increased to 512 and /* moved down memory 5. Worked Examples ================== The following worked examples show the use of LOADSYS and cover most of the aspects of its use. Note that if upper memory has been allocated via the /b, /xx, /xp or /xl options or under DOS 5 via the DOS=UMB command in CONFIG.SYS then this will be used in preference to low memory. 5.1 PRINT --------- An example of a PRINT.BAT file could be: @ECHO OFF loadsys /ss2r print %1 %2 %3 %4 %5 which appears to behave in an identical manner to the normal PRINT command due to the /ss option cutting out all the LOADSYS reporting. The /r option should be omitted for DOS 2.x systems. The PRINT.BAT file must be held in a directory that precedes the directory holding PRINT.COM in the DOS PATH. On a RAL system that would be C:\BAT. Note that as LOADSYS ignores the PRINT.BAT entry when searching down the DOS PATH it will find PRINT.COM in a later directory. A further development on this is to load the PRINT.COM program at the top of memory. To achieve this you have to include details of how much memory is required. For an MS-DOS 3.3 system the LOADSYS command would be of the form: loadsys /ss2roatz25e print %1 %2 %3 %4 %5 where the /z25e option reserves 25e paragraphs to load PRINT.COM. Note that this value was found by loading PRINT.COM with a /z parameter without a value and then experiment (which will crash the machine if the /z value is too low!). The gain is that further TSRs can be loaded into low memory and the removal of PRINT.COM will not leave a gap in memory. Note that the cost is an unused free area at the top memory which was required for the PRINT.COM initialisation code. To simplify the user interface an addition option /u can be introduced into PRINT.BAT in order to unload PRINT.COM. The BAT file could then be of the form: @ECHO off IF %1.==/u. GOTO UNLOAD IF %1.==/U. GOTO UNLOAD loadsys /ss2roatz25e print %1 %2 %3 %4 %5 GOTO EXIT :UNLOAD loadsys /uu print :EXIT And unloading can be achieved by the command: print /u 5.2 Communications Cards ------------------------ Care is needed when unloading communications drivers since the interrupt mechanisms of the card have to be disabled before the driver can be removed from memory. This section gives general details of how this is done and the following sections give specific examples. Two techniques are available. The simplest is to disable the IRQ line that the card is using. This is achieved by setting the appropriate bit in the interrupt mask which is accessed by I/O port 21. This is done via the LOADSYS /p option as detailed in the following table. IRQ LOADSYS Option --- -------------- IRQ3 /p21=2#1xxx IRQ4 /p21=2#1xxxx IRQ5 /p21=2#1xxxxx IRQ6 /p21=2#1xxxxxx IRQ7 /p21=2#1xxxxxxx On reloading the communications driver should reset the mask to enable interrupts again. If it does not then the options above can be used with the 1xx.. set to 0xx.. Whilst this technique often works it has some drawbacks. It will not work where the card has been given a pointer into the driver memory and examples of this are the BICC 16bit and MCA cards. It is also not viable in cases where the IRQ is being shared by several devices as is possible on PS/2 machines. A more hygenic approach is to shut down the card itself and this requires some knowledge of the interface. This can be gleaned from technical documentation or from the code of a driver. A very good source for ethernet cards is the Packet Driver source code which is usually supplied with the driver. The routine RESET_INTERFACE does as its name suggests and mimicing this will achieve the desired result. The following table gives the options required to shut down certain cards. For the ethernet cards it is assumed they are set up for their default I/O port which is usually 300. Card LOADSYS Option ---- -------------- Asynch COM1 /p3f9=0 Asynch COM2 /p2f9=0 BICC 8bit /mc000:10=0 (Assume memory mapped at C000) BICC 16bit/MCA /p828c=4 3COM 3C501 /p30e=80 3COM 3C503 /p300=21 /p307=ff /p30f=0 NE1000/2000 /p31f=ff It is usual to put the option onto the LOADSYS call which loads the communications driver and it will be implemented when the driver is unloaded. This appears to work very well but it is possible to envisage a case where the removal of TSRs that implement higher levels of the protocol could crash the machine as the driver tries to communicate with them in the brief interval before it too is terminated. Moving the option to the first TSR to be unloaded will aleviate this possibility. Most communications drivers can be run in upper memory, the main exception being the 16bit and MCA BICC cards whose drivers must be run below 640K. For the BICC cards this limitation applies right up to the program that communicates with the driver. This includes ETHDRV, BDNINT, PCNFS and the RAL LLCPKT program. The option /ol on the LOADSYS calls will enforce this and since LOADSYS does not object to /ol if there is no upper memory then a BAT file to run in either situation should include it. The following examples illustrate these techniques and also highlight other problems. 5.3 RAINBOW ----------- The following details the loading and unloading of ethernets card with the RAINBOW software. Note that for reasons that are not quite clear RAINBOW is sometimes unable to reestablish contact with the RAL IBM host after the communications software has been unloaded and loaded again. Unloading and loading the whole system or just PINKBOOK usually cures the problem. 5.3.1 RAINBOW over BICC 8 bit card using MPS v3 +++++++++++++++++++++++++++++++++++++++++++++++ A BAT file to run the RAINBOW software could be as follows: : RAIN.BAT - file to load and unload RAINBOW loadsys /sxh cd \isolan loadsys /s bdnldr loadsys /s /mc000:10=0 sfb loadsys /s!xh pinkbook rainbow pinkbook /de loadsys /suu sfb loadsys /suu bdnldr where the RAINBOW.EXE and PINKBOOK.EXE programs are held in a directory in the PATH and the card is at memory address C000. The LOADSYS calls with /xh and /!xh are optional and ensure that the user returns to the directory he started from. Tests suggest that you can get away without disabling the card interrupts. Thus the /mc000:10=0 could be omitted from the SFB load to make a BAT file that was independent of the card location. Be warned that SFB modifies the entry point of BDNLDR when it loads so it is not possible to just load and unload SFB. Even if this modification is corrected and the card reset it has still been found necessary to reload it for reasons which are not understood. 5.3.2 RAINBOW over BICC cards using MPS v4 ++++++++++++++++++++++++++++++++++++++++++ It is recommended that the BICC installation procedure is followed and the parameters for the calls of BICCARB, BICCDLC or MBICCDLC obtained from CONFIG.SYS. Then by removing them from CONFIG.SYS and also the NETCON call in AUTOEXEC.BAT it is possible to load and unload the software. A BAT file to run the RAINBOW software on a 8bit card could be as follows: : RAIN.BAT - file to load and unload RAINBOW loadsys /sxh cd \isolink loadsys /s /m40:a1=0 biccarb.sys loadsys /s /mc000:10=0 biccdlc.sys ST=7 SA=4 netcon loadsys /s!xh pinkbook rainbow pinkbook /de loadsys /suu biccdlc loadsys /suu biccarb where the comments in the previous example apply. MPS v4 uses location 40:a1 to act as a flag and this needs to be reset to zero before the drivers can be reloaded. The 16bit and MCA varients are similar with the BICCDLC.SYS call replaced by the appropriate MBICCDLC.SYS call with the /ol parameter added to prevent loading in upper memory. A general call suitable for both cards would be of the form: loadsys /sol /p828c=4 mbiccdlc.sys /D3 /IA ST=7 SA=4 where the card is at the default I/O Port of 280 for 16bit and 8280 for MCA, using IRQ10 and DMA channel 3. Note the 16 bit machine ignores the top 8 in the 828c port address. In this case disabling of interrupts is done by writing to I/O Port (8)28c where (8)280 is the base port setting. The initial value of the port is 04 and after startup with IRQ10 being used the value becomes 73. Resetting it to 04 at unload disables the interrupts. PINKBOOK appears to work satisfactorily from upper memory so if it could be put there by LOADSYS. Note that it must be unloaded by the PINKBOOK /DE command and not by LOADSYS so that it can be restarted. 5.3.3 RAINBOW over BICC cards using Packet Driver +++++++++++++++++++++++++++++++++++++++++++++++++ An alternate and more memory efficient method of running RAINBOW is over a Packet Driver rather than MPS. This is most relevent when using PADPORT to support a terminal emulator such as EMUTEK or MOS2. Two BAT files are defined called for example PADLOAD.BAT and PADUNLOAD.BAT which load and unload the Rainbow programs. PADLOAD is run first then the application (eg EMUTEK) is run. When it is required to regain the memory used PADUNLOAD is called. Beware of loading any other TSRs or Device Drivers after PADLOAD since they will prevent the memory being reclaimed. For a 16bit and MCA BICC card set up as described previously and with the packet driver using Interrupt 62 the BAT files could be as follows: : PADLOAD.BAT - file to load PADPORT, PINKBOOK and Packet Driver loadsys /sn loadsys /sol /p828c=4 \isolink\mbdndpd.com 0x62 /I10 /D3 loadsys /sol \isolink\llcpkt.com pinkbook padport : PADUNLOAD.BAT - file to unload PADPORT etc padport /de pinkbook /de loadsys /sur llcpkt where MBDNDPD.COM is the packet driver for the BICC 16bit and MCA cards and LLCPKT.COM is the RAL interface program to emulate the MPS interface over a packet driver. Both PINKBOOK and PADPORT could be loaded in upper memory via LOADSYS. 5.3.4 RAINBOW over other cards using Packet Driver ++++++++++++++++++++++++++++++++++++++++++++++++++ For any other card for which there is a Packet Driver available the line: loadsys /s /p828c=4 \isolink\mbdndpd.com 0x62 /I10 /D3 should be replaced with the appropriate call and the /ol option can be omitted. Thus for the 3C501 card on default settings the line becomes: loadsys /s /p30e=80 \3com\3c501.com 0x62 and for the 3C503 card it becomes: loadsys /s /p300=21 /p307=ff /p30f=0 \3com\3c503.com 0x62 5.4 TCP/IP ---------- 5.4.1 PC/TCP over BICC cards ++++++++++++++++++++++++++++ The following gives details of using LOADSYS with the PC/TCP package. Other TCP/IP implementations would be supported in a similar manner. Two BAT files are defined called for example IPLOAD.BAT and IPUNLOAD.BAT which load and unload the TCP/IP kernel. IPLOAD is run first then the various applications (TN3270, FTP or MAIL) are run. When it is required to regain the memory used IPUNLOAD is called. Beware of loading any other TSRs or Device Drivers after IPLOAD since they will prevent the memory being reclaimed. For a 16bit and MCA BICC card the BAT files could be as follows: : IPLOAD.BAT - file to load PC/TCP over MPS v4 loadsys /sn loadsys /sxh cd \isolink loadsys /s /m40:a1=0 biccarb.sys loadsys /sol /p828c=4 mbiccdlc.sys /D3 /IA ST=7 SA=4 netcon loadsys /s!xh loadsys /s \pctcp\ipcust.sys loadsys /sn \pctcp\ifcust.sys loadsys /snol \pctcp\bdnint : IPUNLOAD.BAT - file to unload PC/TCP c:\pctcp\inet unload loadsys /suur ifcust.sys Strictly speaking BDNINT need not be loaded by LOADSYS since the INET call is used to unload it. As is explained in section 8 there is a bug/feature in this system and using LOADSYS corrects for it. If a program such TN3270 or TNVT is used to access another system then it can be loaded by LOADSYS with the /oo option so that when Alt-F10 and ! are used to execute DOS commands the TNx program is swopped out of memory thus allowing larger programs to be run. Note that this inhibits any processing of output from the other system so no indication that a message has been received is given. To reduce memory usage the packet driver interface can be used and in this case the IPLOAD file changes to: : IPLOAD.BAT - file to load PC/TCP over BICC Packet Driver loadsys /sn loadsys /sol /p828c=4 \isolink\mbdndpd.com 0x62 /I10 /D3 loadsys /s \pctcp\ipcust.sys loadsys /sn \pctcp\ifcust.sys loadsys /snol \pctcp\ethdrv 5.4.2 PC/TCP over other cards using Packet Driver +++++++++++++++++++++++++++++++++++++++++++++++++ This is similar to the use with Rainbow. Thus for the 3COM 3C503 card the IPLOAD file now becomes: : IPLOAD.BAT - file to load PC/TCP over 3COM 3C503 Packet Driver loadsys /sn loadsys /s /p300=21 /p307=ff /p30f=0 \3com\3c503 0x62 loadsys /s \pctcp\ipcust.sys loadsys /sn \pctcp\ifcust.sys loadsys /sn \pctcp\ethdrv 5.5 PC-NFS ---------- 5.5.1 PC-NFS over Packet Driver +++++++++++++++++++++++++++++++ The following BAT files will load and unload PC-NFS over the Packet Driver interface for a BICC 16bit or MCA card. : NFSLOAD.BAT - file to load PC-NFS loadsys /sn loadsys /s \nfs\sockdrv.sys loadsys /solof \nfs\pktd.sys loadsys /sol /p828c=4 \isolink\mbdndpd.com 0x62 /I10 /D3 loadsys /soe \nfs\prt * loadsys /snol /i5 /i8 /i17 /i20 /i21 /i27 /i2f /i30 /i31 ... ... \nfs\pcnfs.sys /b1 loadsys /s ansi nfsrun loadsys /su : NFSUNLOAD.BAT - file to unload PC-NFS loadsys /suur pcnfs The example shows the use of the /of for PKTD.SYS in order to prevent LOADSYS doing a flush before unloading the program. If not this will crash the machine. Also noteworthy is that LOADSYS needs notifying of the fact that PCNFS uses several interrupts that dont get activated until NFSRUN is executed. PKTD.SYS and PCNFS.SYS must be in lower memory for BICC 16bit and MCA cards. They can be in upper memory for all other cards. The /oe on the PRT loading is because this program releases its Environment after loading. The /oe prevents this leaving a gap in memory by loading the Environment at the top of memory. Note the /b1 on PCFNFS.SYS to give all ones IP broadcast. This MUST be included at RAL The optional loading and unloading of ANSI.SYS is to cater for NFSRUN which needs it for its highlighted output. This avoids the need to have ANSI.SYS permanently loaded and saves 1600 bytes of memory. Under DOS 5 the option /r will have to be added when ANSI.SYS is loaded since it now uses INT 2F as does PC-NFS. 5.5.2 PC-NFS over 3COM cards ++++++++++++++++++++++++++++ The 3COM 3C503 card is run by a different driver when used with PC-NFS. The NFSLOAD file therefore becomes: loadsys /sn loadsys /s \nfs\sockdrv.sys loadsys /s /p300=21 /p307=ff /p30f=0 /ib /i1c \drivers\vecie5.sys loadsys /s \nfs\nfsvec.sys loadsys /soe \nfs\prt * loadsys /sn /i5 /i8 /i17 /i20 /i21 /i27 /i2f /i30 /i31 ... ... \nfs\pcnfs.sys /b1 nfsrun 5.6 PC3270 ---------- The IBM PC3270 emulator can be run from upper memory by use of the following commands: loadsys /s /p2d4=2#1xxxxxx0 \pc3270\pc3270 nr loadsys /s \pc3270\eehllapi The last line could be omitted if EEHLLAPI is not required. If Alt-5 is used to close down PC3270 then LOADSYS will give a warning message and delete its control block at its next use. A BAT file to perform both loading and unloading could be of the form: : PC3270.BAT - file to load and unload IBM PC3270 v1.x IF %1.==/u. GOTO UNLOAD IF %1.==/U. GOTO UNLOAD loadsys /s /p2d4=2#1xxxxxx0 \pc3270\pc3270 nr loadsys /s \pc3270\eehllapi GOTO EXIT :UNLOAD loadsys /suu eehllapi loadsys /suu pc3270 :EXIT 5.7 MOS2 -------- The RAL 3270 Emulator MOS2 can also be run from upper memory by use of LOADSYS. The MOS2.BAT file should be modified as follows to allow both loading and unloading: IF %1.==/u. GOTO UNLOAD IF %1.==/U. GOTO UNLOAD loadsys /sn loadsys /ss /ib /ic ns_async IF ERRORLEVEL 1 GOTO EXIT loadsys /ss keyio /d %2 IF ERRORLEVEL 1 GOTO EXIT loadsys /ssos mos3270 %1 GOTO EXIT :UNLOAD loadsys /suur mos3270 :EXIT Note that MOS3270 gives side effects hence the /os option and NS_ASYNC uses the async ports and links into INTs C and B. The /u option on KEYIO is best not used unless the memory manager reserves High Memory (the 64K above 1Mbyte). MOS2 can be either unloaded via the normal Alt-Ctrl-Esc mechanism or via the BAT file with the /u option. Note that in the first case LOADSYS will give a warning message when it is next invoked so say what has happened. 5.8 Upper Memory ---------------- The following example gives details of optimising the use of upper memory using QEMM 5.0 or 5.1 on a 386 type machine with VGA. It is not applicable to DOS 5 and later systems where the CONFIG.SYS command DOS=HIGH,UMB should be used along with HIMEM.SYS. CONFIG.SYS should contain something like the following and it is assumed that no EMS memory is going to me used: buffers=1 country=044 437 C:\dos\country.sys shell=c:\dos\command.com c:\dos /e:512 /p device=c:\qemm51\qemm386.sys ram frame=none stacks=0,0 files=40 If EMS is required then the FRAME=NONE should be removed which will reduce the available upper memory by 64K. The AUTOEXEC.BAT could then include the lines after the PATH has been setup: loadsys /sxwt loadsys /sxx loadsys /sxb25 loadsys /sxcou loadsys /sxeou loadsys /soeoa c:\dos\keyb.com uk,,c:\dos\keyboard.sys This moves the BAT file working buffer out of the way, grabs all the upper memory, sets up 25 DOS file buffers, moves the COMMAND.COM and the ENVIRONMENT to upper memory and finally loads KEYB there. This gives something of the order of 595K free memory on a DOS 3.3 system along with upwards of 160K of free upper memory, less 64K on a PS/2. The /xc and /xe options have /ou to abort them if no upper memory exists. A subsequent call to a BAT file as shown previously could load a communications system in upper memory. Where these had a hot key switching system, such as in MOS2 or PC3270, you would have communications available all the time and no extra memory cost. 6. Bugs/Features and Problem Programs ===================================== The following list of programs need special action when being run under LOADSYS. It is based upon limited experience so only covers a few cases at present. BICC ethernet cards - see worked examples above. ISOLINK.COM v1 - this was the first version of MBDNDPD, the packet driver for BICC 16bit and MCA cards. It has a very interesting bug/feature. In searching to find the BICC Ethernet card via the PS/2 POS system it uses I/O Port 96 to select which adapter card to interrogate and on exit leaves the register pointing to the card. Unfortunately there is a bug in the BIOS of early PS/2s in that when INT 15 Function C0 is used to find out details of the machine this gives the reply that the function is not implemented. This is because it assumes I/O Port 96 is pointing to the motherboard. The solution is to reset the value of I/O Port 96 to zero after ISOLINK.COM has been loaded as follows: loadsys /sp828c=4 isolink.com 0x62 /I10 /D3 loadsys /sp96=0 Known ramifications of this problem are that the PS/2 Mouse will not load and that XVIEW will only run once. CEMM.EXE and EMM386.EXE - These EMM drivers can be loaded but note that the full name must be given to avoid confusion with .COM varients and the /od option must be given to load it as a Device Driver. For example: loadsys /od emm386.exe 386MAX - this EMM cannot be unloaded by LOADSYS and although it claims to support XMS upper memory tests show this not to be the case so the /xx option does not work. The version of EMM386 supplied with Windows 3 does not support DMA therefore communications cards such as the BICC 16 bit and MCA versions will not work in a Windows 3 virtual machine. This does not apply to the DOS 4 and DOS 5 versions though reports suggest this may be machine dependent. HIMEM.SYS - use /i15 option as it chains into this interrupt after startup. The Novell NET5.COM program can be run from upper memory but when called with the /u option will not unload. It should not be unloaded by LOADSYS as it will crash the PC. Moving the DOS Environment into upper memory via LOADSYS /XE causes the LOGIN to the Novell Server to lock the machine. PC3270.COM - the IBM 3270 Emulator on an IBM PS/2 requires the IBM 3278 card to be disabled at unloading with the option /p2d4=2#1xxxxxx0. This is also recommended on all other machines but does not appear to crash the machine if ommitted. The /oe option should not be used as this program accesses its copy of the environment. As PC3270 has an unloading option LOADSYS should only be used when it is required to load PC3270 elsewhere in memory. Some programs object to the use of the top of the 640K memory by LOADSYS Control Blocks. Examples are Windows 3 and any program that extends memory into the video area such as VIDRAM which comes with QEMM386. Using the /oa option makes LOADSYS put the control block adjacent to the program. The following programs should either not be run with the /r option or have the offending interrupt (usually the one used to access the program) specifed by /i to make it direct. BICC Ethernet board drivers: BICCDLC.SYS & MBICCDLC.SYS CEMM.EXE - Compaq 386 EMM driver PINKBOOK.EXE from the RAINBOW communications software. PRINT.COM under DOS 2.1. Any program that implements the Packet Driver interface for ethernet. Examples are MBDNDPD.COM and PBDNDPD.COM. Programs such as Sidekick which insist on being at the head of an Interrupt chain. The following are other problems with TSRs which have been noted: Most TSRs with the facility to unload themselves (eg PINKBOOK /DE) do not close the four files (CON input and output, AUX and PRN) that DOS opens by default for all programs. The net result is that the DOS File Handle Cnt (as shown by LOADSYS /LF) is incremented at each load but not decremented at unload. No problems have been noted as a result of this but on machines that are never switched off and TSRs are frequently loaded and unloaded things may go bang when the count goes negative. LOADSYS unloads TSRs via DOS which thus closes any open files and resets the handle counters. Interesting side effects have been observed with TSRs written in C and compiled with the Microsoft C compiler. This is because programs produced by this compiler link into various interrupts when they are run and unlink at termination. A TSR therefore has to be very careful when it wishes to link into any of these interrupts. It is highly likely that the same problem will occur with Microsoft Pascal. This problem was highlighted by the TCP/IP BDNINT and ETHDRV programs which for reasons which are not quite clear link into INT 0. The program INET is used to unload them but this fails to reset INT 0 back to its correct value thus leaving it pointing into the memory the TSR has just vacated. The reason appears to be that INET, being a C program, links into INT 0 and then commences to unload the TSR and unlink its interrupts including INT 0. However when INET terminates it sets INT 0 back to its original value which points to the now unloaded TSR. The solution is to load such programs with LOADSYS and after they have been unloaded by INET the next call to LOADSYS will detect their removal and correct the problem. 7. Differences in LOADSYS versions ================================== 7.1 Version 1.0 --------------- First release to prove that the techniques worked. 7.2 Version 1.1 --------------- This version will not work with programs that have already been loaded with version 1.0 as the LOADSYS Control Block format has been changed. LOADSYS will detect this and abort. Before a program is unloaded LOADSYS now checks to see if any Interrupt Vectors in the range 0 to 7F point into its address space. If so it refuses to do the unload just in case the program has linked into a further interrupt during its execution. To override this limitation the option must be specified twice. Thus the command loadsys /uu will force an unload to take place. The /i option allows these extra interrupts to be noted. LOADSYS is now able to load EXE files that are Device Drivers - this did not work in v1.0. In order to add new facilities several options have had to be changed. Aplogies for the inconvenience this causes. The changes follow. Variants of the /o (override) option now replace the following options: /i - use internal DOS loader now /oi (override internal loader) /d - force loading as a device driver now /od (override device driver) /p - force loading as a TSR now /ot (override TSR) /v - force release of Environment now /oe (override Environment) /a - in conjuntion with loading a program to locate control block adjacent to the program now /oa (override adjacent) Other changes are: /ua - unload all programs now /ur (unload repeat) and the use of a filename in this context now indicates where to start unloading. /s - stop a program - now /d (disable) /g - go a stopped program - now /e (enable) /q - quiet now /s (silent) /m - move now /q (squeeze) The /a option now gives additional information at load and unload times. /iαα option introduced to allow extra interrupts to be noted /mαααα:αααα option introduced to display and reset memory values. /pαααα option introduced to display and reset I/O Port values. 7.3 Version 1.2 --------------- There have been no changes to any options so BAT files for version 1.1 should still work. LOADSYS now reserves one paragraph at the top of memory in order to facilitate the expanded memory facilities. The /os option to override side effects was incorrect in version 1.1 in that it did not record any changed interrupts. LOADSYS can now load QEMM.SYS and also very large EXE files - this did not work on previous versions. The /b option can be used to extend the DOS memory management upto 1Mbyte thus allowing upper memory to be easily utilised. LOADSYS can now unload any 386 Expanded Memory Manager such as QEMM and EMM386. The only exception so far found is 386MAX which has no abort mechanism. LOADSYS can also change the ROM shadowing on Compaq machines when loading such drivers or directly via the /xr option. It can also interface to any LIM 3.2 or 4.0 driver and make use of the memory pages these provide via the /xp or /xl options. The /xb option allows the DOS file buffer chain to be extended and suppliments the BUFFERS parameter in CONFIG.SYS. The /xp option extends the memory management into memory above 640K provided by an Expanded Memory Manager. The /xl does the same but leaves a window whereby LIM memory may be accessed. The /xc option allows COMMAND.COM to me moved and the /xe does the same for the DOS Environment. The /xt option moves the PS/2 Extended BIOS Data Area The /xf option fiddles the DOS memory chain to hide the control blocks at the end of lower memory. The /ls option lists various relevent system features including available free memory. The /lb option to list memory blocks does not now show those blocks occupied by LOADSYS itself. 7.4 Version 1.2a Bug Fix Release -------------------------------- When no stack was specified it was incorrectly positioned after the program and not just before the end. 7.5 Version 1.3 --------------- Version 1.3 is incompatible with previous versions because it has changed its control block formats. Therefore if you have already used a previous version to load programs this version will complain. Just install v1.3 and reboot the machine to cure it. There are no major changes in the v1.2 options so these should still work with v1.3. The error and warning message system has been improved and the program name LOADSYS precedes all such messages when the /s option has been given so you have a sporting chance of finding out from where it originated. As a result additional warning messages may appear compared with v1.2 - the /ss option will surpress them. The /xx option allows LOADSYS to obtain memory from XMS memory managers. The /xh option records the current directory as home and /!xh returns to it. The /xb option now sets up file buffers for DOS 4.x systems. The /xw option moves BAT file working buffers. The /xc and /xe options operate on the COMMAND.COM and Environment of the current COMMAND.COM not the top level one as previously. A bug has been fixed in /xc whereby if EXIT was used on a moved COMMAND.COM it crashed the machine. The /z option with the /xe option sets the size of the DOS Environment if it is greater than the original value. This allows the Environment to be increased in size when running under a secondary COMMAND.COM. The /ou option forces loading in upper memory and causes a failure if it does not exist. The /oq option causes LOADSYS to quit if any option generates a warning message. The /xf option implementation has been changed but its function is still to remove memory fragmentation prior to loading control programs such as Windows 3 and DESQview. The /oo option allows programs to be overlayed out of memory when they run other programs. The /r option can now be given with /q so that all possible programs are moved in memory. Some checks for the restrictions of DR-DOS v5 have been added though the tests were by no means exhaustive. The worked examples have been updated to reflect the latest versions of software and to fix errors notably in the NFS example. A bug whereby filenames greater than eight characters corrupted the LOADSYS control block has been fixed. A bug whereby side effect interrupts were not recorded correctly has been fixed. A bug in the /wl option whereby it did not load large files below the given value has been fixed. A bug whereby LOADSYS when unloading a program gave a long list of interrupts that it claimed were pointing to the program has been fixed. It only occurred on certain BIOS' such as those found on Tandon PCA machines. A bug whereby LOADSYS failed under DESQview has been fixed. 7.6 Version 1.3a Minor Enhancement and Bug Fix Release ------------------------------------------------------ The restriction that the /r (Redirection) and /i (Interrupt) options cannot occur together has been removed. All Interrupts specified by /i will not be redirected. Hence a mixture of redirected and direct interrupts is possible. The /lb (List Memory Blocks) option is now better annotated. The option /lp lists the those memory blocks containing programs. /? now gives help A filename used to denote a program already loaded can end in a * to indicate a wildcard. If an attempt to unload a device driver failed because its interrupts were in use by another program then the driver was left disabled and a subsequent attempt to unload it crashed the machine. This is now fixed. There is a very obscure bug whereby in some cases when the /XC option has been used under DOS 4 to move COMMAND.COM an attempt to DEL a read only file crashes the machine. Fixed in v1.3b. Limited testing has been done under a beta release of DOS 5. It has not proved possible to implement XB (Increase DOS file buffers) and XC (Move COMMAND.COM) only works for Secondary command processors. The first limitation is fixed in v1.4, the second is permanent. The /xr and /!xr to switch Compaq ROM shadowing on and off stopped working in v1.3 because a reorganisation of the code somehow dropped the call to the routine. Now reinstated. There was a bug in the treatment of side effects (Interrupts changed on loading a program which did not point to it) in that they were never reset on unloading. The meaning of the /os option has therefore been changed in that it now means dont report side effects. In order to have the side effect reset back when a program is unloaded the interrupt must now be specified via the /i option. Some problems with TSRs that move themselves in memory after loading have been fixed. However this area is rather fraught so may continue to give problems. 7.7 Version 1.3b Minor Enhancement and Bug Fix Release for DOS 5 ---------------------------------------------------------------- LOADSYS gave error messages when the DOS=UMB command was present in CONFIG.SYS. This is because this command extends the DOS 5 memory chain into Upper memory in the same way as LOADSYS does and confused the latter. Now fixed. When the DOS=HIGH command is present in CONFIG.SYS then DOS 5 is run with address wrap round disabled so that it can access the memory above 1Mbyte. This is done by enabling the A20 address line. When a program is loaded the A20 line is disabled thus allowing wrap round again. This has been added to LOADSYS and programs such as BDNINT and ETHDRV which used wrap round will fail on previous versions. Note there is a bug/feature in that any interaction with DOS disables wrap round on entering DOS but does not reinstate it on returning to the program. Thus any program that uses wrap round after accessing DOS will fail. 7.8 Version 1.4 --------------- Version 1.4 is incompatible with previous versions because it has changed its control block formats. Therefore if you have already used a previous version to load programs this version will complain. Just install v1.4 and reboot the machine to cure it. There are no major changes in the v1.3 options so these should still work with v1.4 but note the next two paragraphs. V1.4 is fully compatible with DOS 5 but as this has required major recoding and hence possibly new bugs you are advised to keep a copy of v1.3 just in case. LOADSYS now detects the use of Expanded, Extended and the HMA memory by a program when it is loaded and releases such memory when the program is unloaded. It will also detect when a program chains into the XMS driver and will correct this at unloading. The option /om overrides these features. The option /a will give details of the use of such memory at loading, unloading and listing via the /l option. This is the most likely new feature to give problems in cases which worked with v1.3 and the /om option should revert back to the v1.3 method of working. The /oh option allows certain types of program to be loaded into the HMA. Details of Extended, Expanded and HMA memory availability are now displayed by option /ls. Adding /a gives further details. There was a bug in v1.3 whereby if upper memory was obtained via both the /xx and /xp options then this corrupted the XMS memory chain. Subsequent use of the XMS gave incorrect values for the amount of free memory. This has now been fixed. The XMS memory block chain in upper memory can be listed by the /lx option. The /ok option now keeps LOADSYS where it is when loading a program. This is only required where a program relocates itself to the top of low memory which is where LOADSYS would normally have moved itself to. Further problems with upper memory provided via the DOS=UMB command in CONFIG.SYS have been fixed. The option /xf to remove fragmentation now works with the DOS=UMB command and retrieves 4k bytes of memory that is normally lost when Windows 3 is loaded. When operating with the /s option and an error or warning occurs LOADSYS now displays the command that generated it. The option /* allows a comment to be added to a LOADSYS command except where programs are being loaded. LOADSYS now works with the 4DOS command processor and has been tested with v3.02. Despite claiming to be compatible with COMMAND.COM this program appears not to allow memory blocks at the top of low memory. Thus loading with /t fails and the LOADSYS Control Block must always be adjacent to the program (option /oa). Thus when running under 4DOS the /t is not allowed and /oa is forced on program loading. 7.9 Version 1.4a Bug Fix Release -------------------------------- Some debugging calls to INT 3 were inadvertantly left in the code. Now removed. 7.10 Version 1.4b Minor Enhancement Release ------------------------------------------- There was a bug in the interpretation of a named program in that LOADSYS searched through the order in memory ignoring the loading order. This was only noticeable when upper memory was in use and programs with the same name, either identical or due to wildcard matching, were being accessed. Therefore the meaning of filename has been redefined and this is best explained by an example. Consider the command: loadsys /u filename where filename can be a complete name or may end in a * to give a wildcard match. This will unload the last program to match this name in the order of loading. ie. Last load, last unload. To change this to the first loaded program the option /1 should be given. This has the consequence that a filename of just * now unloads the last program to be loaded or, if /1 is given, the first. Bugs fixes in /l listing for upper memory and HMA indication have been made. Minor improvements to /lb listing made for orphan blocks. 8. Support and Acknowledgements =============================== Some of the techniques used in LOADSYS were described in the program DEVADD by Giles Todd in .EXE Vol 4, Issue 3, August 1989. LOADSYS is supplied free and is supported for all users at RAL on IBM PC and PS/2 computers and near clones. Users outside RAL are requested in the first instance to obtain copies and help from their normal support sources. Academic user support organisations may seek help from RAL but the latter will only be given on a 'best endeavours' basis. There is no support for other organisations other than by private arrangement with the author. Updates of the software may be file transferred from the binary file LOADxx EXE (xx being version number without a point - currently 14) on the RAL IBM mainframe (UK.AC.RL.IB) disc PCSOFT 192. Executing the file will produce the program and documentation. Further details of how this is done can be obtained by email from the author. Bug reports or problems should be reported, ideally by email, to Graham Robinson: Via JANET : GWR@UK.AC.RL.IB G W Robinson Via Internet : GWR@IB.RL.AC.UK Atlas Centre UK Telephone : 0235 44 5636 or 6391 Rutherford Appleton Laboratory International: +44 235 44 5636 Chilton, Didcot Oxon,OX11 0QX,UK